<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
  <title>Eclipse 3.0 Runtime Adoption Guide</title>
  <link rel="stylesheet" href="/default_style.css">
</head>
  <body link="#0000ff" vlink="#800080">

<p align="right"><img src="file:///D|/equinox/ngibmcpy.gif" alt="Copyright IBM Corporation and others 2000, 2003." border="0" width="324" height="14"></p>
<table border="0" cellspacing="0" cellpadding="2" width="100%">
      <tbody>
        <tr>
          <td align="Left" valign="Top" colspan="2" bgcolor="#0080c0"><b><font face="Arial,Helvetica"><font color="#ffffff">
 Eclipse Corner Article</font></font></b></td>
        </tr>
  </tbody>
</table>

<div align="Left">
  <h1><img src="file:///D|/equinox/prototype/plugins/images/Idea.jpg" height="86" width="120" align="Center">
  </h1>
</div>

<h1 align="Center">Eclipse 3.0 Runtime Adoption Guide</h1>
<blockquote>
  <p><b>Summary</b><br>
    <center>
      <b>This is a draft document. </b>
    </center>
    <br>
    This document details the steps required to <b>adopt</b> the new mechanisms
    found in the Eclipse 3.0 runtime. In most cases, plug-in developers do not
    need to follow these steps as the 3.0 runtime supports the 2.1-style API.
    However, the new runtime offers significant new <i>experimental</i> function.
    It is this function which is detailed here. </p>
  <p><b> By Jeff McAffer, IBM OTI Labs</b><br>
    <font size="-1">June 24, 2004</font></p>
</blockquote>
<hr width="100%">

<h2>Preamble</h2>
<p>This content has been moved to the Migration Guide and the Javadoc deprecations
  as appropriate.</p>
<h3>Plug-ins and bundles</h3>
<p>This content has been moved to the Migration Guide and the Javadoc deprecations
  as appropriate.</p>
<h3><a name="registries"></a>Registries and the plug-in model</h3>
<p>This content has been moved to the Migration Guide and the Javadoc deprecations
  as appropriate.</p>
<h3>Legacy code</h3>
<p>This content has been moved to the Migration Guide and the Javadoc deprecations
  as appropriate.</p>
<h3>Updating plugin/fragment files</h3>
<p>The new runtime is based on an implementation of the OSGi framework specification.
  The OSGi specification mandates the use of MANIFEST.MF files to define the execution
  of a plug-in. This conflicts with the Eclipse notion of plugin.xml as far as
  &lt;runtime&gt; and &lt;requires&gt; elements are concerned. The easiest way
  to update your plugin.xml or fragment.xml is to use the PDE Migration Tool (PDE
  Tools-&gt;Convert to OSGi bundle).</p>
<p>In certain situations the conversion tool is unable to correctly determine
  all of the packages provided by a plug-in. In particular, if a plug-in declares
  a library entry for say foo.jar but does not contain foo.jar, the converter
  is unable to generate the appropriate provides-package entries in the output
  manifest (this is done by analyzing the supplied jar which, in this case, is
  not present). Plug-in or fragments which are fully self-contained are converted
  correctly. </p>
<p>This tool extracts the execution-specific information from your plugin.xml
  and puts into the OSGi mandated META-INF/MANIFEST.MF file. All extension-related
  information is left in the plugin.xml. The manifest is a standard Java Jar file
  manifest. It contains specifications for the execution elements of our plug-in
  (e.g., classpath, prerequisites, ...). A table of frequent mapping is included
  below while the full <a href="http://www.osgi.org">OSGi specification</a> has
  enumerates all pre-defined manifest headers.</p>
<table width="100%" border="1">
  <tr>
    <td>
      <div align="center"><b>plugin.xml tag/attribute</b></div>
    </td>
    <td>
      <div align="center"><b>manifest.mf header</b></div>
    </td>
  </tr>
  <tr>
    <td>&lt;plugin id=&gt;</td>
    <td>Bundle-SymbolicName</td>
  </tr>
  <tr>
    <td>&lt;plugin version=&gt;</td>
    <td>Bundle-Version</td>
  </tr>
  <tr>
    <td>&lt;plugin name=&gt;</td>
    <td>Bundle-Name</td>
  </tr>
  <tr>
    <td>&lt;plugin provider=&gt;</td>
    <td>Bundle-Vendor</td>
  </tr>
  <tr>
    <td>&lt;plugin class=&gt;</td>
    <td>Bundle-Activator</td>
  </tr>
  <tr>
    <td>&lt;fragment plugin-id=&gt;</td>
    <td>Fragment-Host</td>
  </tr>
  <tr>
    <td>&lt;fragment plugin-version=&gt;</td>
    <td>Fragment-Host: &lt;id&gt;; bundle-version=</td>
  </tr>
  <tr>
    <td>&lt;requires&gt;, &lt;import&gt;</td>
    <td>Require-Bundle</td>
  </tr>
  <tr>
    <td>&lt;runtime&gt;, &lt;library&gt;</td>
    <td>Bundle-ClassPath</td>
  </tr>
</table>
<p>The extension/extension-point related information continues to be detailed
  in the plugin.xml file however the following aspects of the plugin.xml DTD are
  being deprecated.</p>
<ul>
  <li>all attributes on the &lt;plugin&gt; tag</li>
  <li>&lt;runtime&gt; and its &lt;library&gt; subelement</li>
  <li>&lt;requires&gt; and its &lt;import&gt; subelement</li>
</ul>
<p>This leaves the plugin.xml containing only the &lt;plugin&gt;, &lt;extension&gt;
  and &lt;extension-point&gt; tags</p>
<p>Note also that the form of this content is not specific to a plug-ins vs. fragments.
  As a result, the fragment.xml file is being deprecated and renamed to plugin.xml
  with the outlined DTD changes. In most cases fragments do not supply extensions
  or extension-points so the bulk of the change required is done while moving
  to the MANIFEST.MF file and the fragment.xml file can be deleted.</p>
<p>The <tt>plugin.properties</tt> file continues to supply translations for the
  extension/extension-point information in plugin.xml and also supplies translations
  for various keys in the MANIFEST.MF.</p>
<p>The build.properties file remains unchanged.</p>
<h3>&nbsp;</h3>
</body>
</html>
